Eureka服务注册与发现

	# 介绍

		1、Spring Cloud Euraka介绍

			Spring Cloud Euraka是Spring Cloud集合中一个组件，它是对 Euraka 的集成，用于服务注册和发现。
			Eureka是Netflix中的一个开源框架。它和 Zookeeper、Consul一样，都是用于服务注册管理的，同样，Spring Cloud还集成了Zookeeper和Consul。

			在项目中使用Spring Cloud Euraka的原因是它可以利用Spring Cloud Netfilix中其他的组件，如zull等，因为Euraka是属于Netfilix的。

		2、Euraka介绍

			Eureka 由多个 Instance(服务实例)组成，这些服务实例可以分为两种：Eureka Server和Eureka Client。
			为了便于理解，我们将 Eureka Client 再分为 Service Provider和Service Consumer。

			三大角色:
			Eureka Server(提供服务注册和发现)提供服务注册和发现.
			Service Provider(服务提供方)将自身服务注册到 Eureka，从而使服务消费方能够找到.
			Service Consumer(服务消费方)从Eureka 获取注册服务列表，从而能够消费服务.

		3.建项目步骤

			(1)导入依赖包

			<!--Eureka-->
	        <!-- https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-starter-eureka -->
	        <dependency>
	            <groupId>org.springframework.cloud</groupId>
	            <artifactId>spring-cloud-starter-eureka</artifactId>
	            <version>1.4.7.RELEASE</version>
	        </dependency>

			(2)编写配置文件 

			Server注册中心 提供者 消费者 各个模块的配置文件有各自的写法

			(3)开启这个功能 @EnableXXXX
			
			(4)配置类

		4.Eureka 的自我保护机制(好死不如赖活着)

			0、某一时刻某一个微服务不能用了(如:dept8001xxx),而Eureka不会自动清除，依然对微服务的信息进行保存

			1、在默认的情况系，EurekaServer在一定的时间内没有接受到微服务的实例心跳，EurekaServer将会注销该实例(默认为90秒)

			2、但是在网络发生故障的时候,微服务于EurekaServer之间是无法通信的，这种情况就非常危险了，因为微服务本身实例是健康的，此刻本不应该注销这个微服务。
			那么Eureka自我保护模式就解决了这个问题了

			3、当EurekaServer节点在短时间内丢失过多的客户端时(包含发生的网络故障)，那么节点就会进行自我保护

			4、一但进入自我保护模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据不会注销任何的微服务

			5、当网络故障恢复后，该EurekaServer节点会自动的退出自我保护机制

			6、在自我保护模式中，EurekaServer会保护服务注册表中的信息，不在注销任何服务实例，当重新收到心跳数恢复阀值以上时，
			该EurekaServer节点就会自动的退出自我保护模式，这种社设计宁可保留错误的服务注册信息，也不盲目的注销删除任何可能健康的服务实例

			7、自我保护机制就是一种对网络异常的安全保护实施，他会报错所有的微服务(健康或者不健康的微服务都会保存)

			，而不会盲目的删除任何微服务，可以让 Eureka集群 更加的健壮/稳定

			8、在EurekaServer端可取消自我保护机制不建议使用(euraka.server.enable-self-preservation = false 禁用自我保护机制)

		5.Eureka和ZooKeeper的区别

			RDBMS==>（MySql,Oracle,SqlServer等关系型数据库）遵循的原则是：ACID原则（A：原子性。C：一致性。I：独立性。D：持久性。）。

			NoSql==>（Redis,Mogodb等非关系型数据库）遵循的原则是：CAP原则（C：强一致性。A:可用性。P：分区容错性）。

			在分布式领域有一个很著名的CAP定理：C：数据一致性。A：服务可用性。P：分区容错性（服务对网络分区故障的容错性）。

			在这个特性中任何分布式系统只能保证两个。

			CAP理论也就是说在分布式存储系统中，最多只能实现以上两点。而由于当前网络延迟故障会导致丢包等问题，所以我们==分区容错性==是必须实现的。
			也就是NoSqL数据库P肯定要有，我们只能在一致性和可用性中进行选择，没有Nosql数据库能同时保证三点。（==>AP 或者 CP）

			==Eureka和Zookeeper就是CAP定理中的实现，Eureka（保证AP），Zookeeper（保证CP）==

			==图片==
			==图片==

			Zookeeper的设计理念就是分布式协调服务，保证数据（配置数据，状态数据）在多个服务系统之间保证一致性，
			这也不难看出Zookeeper是属于CP特性（Zookeeper的核心算法是Zab，保证分布式系统下，数据如何在多个服务之间保证数据同步）。
			Eureka是吸取Zookeeper问题的经验，先保证可用性。


